1. Field of the Invention
The present invention generally relates to computer networks including shared resources and, more particularly, to computer networks selectively providing access to information to a plurality of users through a web browser/server interface in accordance with user credentials.
2. Description of the Prior Art
With the growing familiarity and ubiquity of the Internet and World Wide Web for exchange of information, similarly styled and functioning information exchange systems are being provided on more or less private intranet (e.g. within a business or organization) and extranet (among a select group of cooperating businesses or organizations) network systems for exchange of data among, for example, employees of an organization or company connected thereto. The familiarity of users with internet browsers enhances their efficiency and comfort with using systems which operate similarly and provide similar interfaces in intranet and extranet communication systems in their workplaces.
Such systems can employ firewalls, virtual private network technology, or other technologies to limit access to computing resources to some subset of users, and thus completely deny access to others. On the other hand, some computing resources are openly contactable by nearly everyone in an enterprise. In either case, there can be scenarios where only a subset of people who can contact a resource should be capable of accessing the information provided by the resource. This is true even of a situation where firewalls exist to create enclaves of users that have exclusive access to resources within their respective enclaves, because a resource may have to be placed in a common area so that selected individuals from multiple enclaves get appropriate access.
When the computing resource is web information, most web servers provide for this additional security need by enforcing a user authentication, establishing a Discretionary Access Control (DAC) credential for the user, such as a group or a role, and then performing access control on HTML requests at either the directory or file level. However, there are situations where organizations either need specialized web data access using Mandatory Access Control (MAC) which assigns data both classifications and compartments, or where organizations require that portions of individual HTML files be labeled such that only certain users see certain portions of the file. Such capabilities are not supported by native web server security. Nor are they supported by other industry products that typically install middleware on clients and servers as the basis for the digital certificate or Kerberos ticket exchanges, so as to perform authentication and enforce access control to web and non-web network resources. For example, such products still provide a DAC access control mechanism, and any fine-grained labeling of objects is supported to a file level or data base record level, but labeling is not applied internally of ASCII files, such as static HTML pages.
Several concepts are involved in known Internet, intranet and extranet arrangements which are exploited in a modified and enhanced form in the invention, known forms of which will now be discussed. A first concept is that of the Common Gateway Interface (CGI) and a second concept is that of the "cookie".
In regard to known CGIs, most web page access is performed using a so-called simple URL (an acronym for Universal Resource Locator) of the form
"http://domain.com/dir/pag.html". PA1 "http://domain.com/cgi-bin/program/extrapath/parm1=value1&parmN=valueN". Such a URL tells the web server to execute the CGI program "program", providing additional path information as specified by "extrapath" and providing any desired number of parameter values (e.g. parm1 and parmN) to the CGI program. The CGI program then executes and provides the result, in HTML format, which the browser can interpret and display.
This directs the web server, also known as the "httpd server", managing the web site domain "domain.com" to retrieve the static HTML page "pag.html" from a directory called "dir" that is, itself, a subdirectory of a single and well-known directory on the web server.
In contrast, a generalized URL invoking a CGI interface directs the web server to invoke another program, a CGI program, which builds the contents of the HTML page to be presented to the user in accordance with parameters provided in a generalized URL (hereinafter sometimes "CGI URL" to indicate this function in the context of the invention). Essentially a CGI program is a stateless interface which executes, when invoked and utilizing parameters provided in the "CGI URL", to provide a single service to the network user. Generalized URLs for performing such a function are more complex and of the form
The concept of a "cookie" is an incident of the fact that CGI programs are stateless interfaces performing the function of building a response each time invoked and, while uses of the CGI program may be logged, the result of the use is not. Generally the "cookie" facility allows the CGI program to maintain state for a browser session. The CGI is free to assign whatever kind of state it wants to a cookie value it assigns to a browser and could be considered as providing browser session identity (but not necessarily user identity).
A "cookie" name and value get assigned to a browser for a specific web server domain. This occurs when a CGI script assigns a cookie name and value into the Hypertext Transfer Protocol (HTTP) header portion of the HTML reply that is sent back to the browser. The cookie name and value are then echoed back to the web server at the identified domain whenever the browser issues another HTTP request to the web server. Thus, the cookie name and value are present at both the web browser and web server. The server can continue to set different values, or set new cookie names, as it desires. This cookie data thus provides a means of having the web server maintain and recognize state information across multiple client requests. Cookies are also assigned lifetimes by the web server; if finite, the cookie name and value are stored in a disk file at the browser, tied to the domain name. If no expiration is specified, cookies only live in browser memory (but not on disk), and are in effect for only as long as the browser is not terminated.
A "cookie" value is assigned by a CGI script and is unique to the domain. As is known in the art, the "cookie" is a passive (in at least the sense that the user has no control over its content) group of data, generally randomly assigned and may be stored in a file at the user's browser (in connection with assignment of a lifetime parameter). The "cookie" value, once assigned, can then be sent to the client browser by the web server. The client browser then returns it with each transaction requested during the session. Thus, the cookie is available at both the domain and the web server for each transaction in the session and can associate the transactions in the session with a particular domain.
It should be noted that neither CGI programs nor cookies, as presently known and used in the art, have any security implications. The cookie merely allows a web server to, at most, infer information about what occurred on previous transactions from the browser. Strictly speaking, even this is not necessarily true, if a user alters the cookie value as stored in the disk cookie file. Such an act does not actually defeat or "spoof" security aspects of the server, although it can make the web server act differently. In fact, cookie names and values can never be used as the basis for providing security features, unless they are utterly hidden from users, to prevent cookie inspection or alteration.